src/commands/support/ask.ts:148

• In the catch block, --json mode still logs a human-readable failure message (including chalk styling) and then calls this.error(), which will pollute JSON output. Prefer using this.jsonError({ error: errorMsg, success: false }, flags) (or equivalent) when shouldOutputJson(flags) is true, and avoid any non-JSON logging in that branch so JSON consumers get a clean error object plus a non-zero exit code.

src/commands/channels/presence/enter.ts-43-46 (1)

43-46: ⚠️ Potential issue | 🟡 Minor

Restore the canonical --duration description text

The new description omits the 0 behavior, which makes CLI semantics less clear. Please keep the standard wording.

Suggested patch

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/channels/presence/enter.ts` around lines 43 - 46, Update the
duration flag description to the canonical text: change the Flags.integer option
for the duration flag (symbol: duration) so its description reads "Automatically
exit after N seconds (0 = run indefinitely)" and ensure the alias remains char:
"D" (i.e., restore the original wording while leaving required: false and other
options unchanged).

src/commands/apps/set-apns-p12.ts-57-59 (1)

57-59: ⚠️ Potential issue | 🟡 Minor

Progress message should end with ....

As per coding guidelines, progress messages must end with ... to indicate an in-progress action.

Proposed fix

      this.log(
-        progress(`Uploading APNS P12 certificate for app ${resource(args.id)}`),
+        progress(`Uploading APNS P12 certificate for app ${resource(args.id)}...`),
      );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/apps/set-apns-p12.ts` around lines 57 - 59, Update the progress
message passed to progress(...) so it ends with an ellipsis; specifically modify
the call in set-apns-p12 where this.log(progress(`Uploading APNS P12 certificate
for app ${resource(args.id)}`)) is used to append "..." to the string so the
progress output follows the guideline (i.e., ensure the template literal given
to progress includes trailing "...").

src/commands/channels/subscribe.ts-63-65 (1)

63-65: ⚠️ Potential issue | 🟡 Minor

Restore the standard --duration help text.

The description should include the indefinite-run behavior to match command help consistency.

Suggested patch

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/channels/subscribe.ts` around lines 63 - 65, Update the duration
flag's description in src/commands/channels/subscribe.ts: change the
Flags.integer({ description: ... , char: "D" }) entry so the description reads
"Automatically exit after N seconds (0 = run indefinitely)" and ensure the alias
remains char: "D" to match the standard help text for the --duration/-D flag.

src/services/history-manager.ts-40-43 (1)

40-43: ⚠️ Potential issue | 🟡 Minor

Empty catch block violates ESLint no-empty rule.

The catch block at lines 40–43 contains only comments with no statements. ESLint 9's recommended rules enable no-empty by default; this will fail linting. Add a no-op statement to satisfy the rule while preserving the intended error-suppressing behavior.

Suggested fix

    } catch (error) {
      void error;
      // Silently ignore history load errors
      // History is a nice-to-have feature, shouldn't break the shell
    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/services/history-manager.ts` around lines 40 - 43, The empty catch block
in history-manager.ts (the catch following the try that loads history, e.g., in
the loadHistory routine) violates ESLint no-empty; add a no-op statement inside
that catch (for example a void 0 expression statement) so the block is not empty
but preserves the silent error-suppressing behavior—do not change error handling
semantics or add throwing behavior.

src/commands/integrations/delete.ts-99-103 (1)

99-103: ⚠️ Potential issue | 🟡 Minor

Use dim styling for secondary field labels in the detail block.

Lines 99-103 currently print plain labels; they should use chalk.dim() to match the pattern used throughout the CLI for secondary labels in structured output.

Proposed fix

+import chalk from "chalk";
 import { Args, Flags } from "@oclif/core";
@@
-        this.log(`ID: ${integration.id}`);
-        this.log(`App ID: ${integration.appId}`);
-        this.log(`Type: ${integration.ruleType}`);
-        this.log(`Source Type: ${integration.source.type}`);
+        this.log(`${chalk.dim("ID:")} ${integration.id}`);
+        this.log(`${chalk.dim("App ID:")} ${integration.appId}`);
+        this.log(`${chalk.dim("Type:")} ${integration.ruleType}`);
+        this.log(`${chalk.dim("Source Type:")} ${integration.source.type}`);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/integrations/delete.ts` around lines 99 - 103, The printed
detail labels for integration fields (ID, App ID, Type, Source Type) are plain
text; update the output to use chalk.dim() for secondary labels to match CLI
styling—wrap the label portions passed to this.log (the strings like "ID:", "App
ID:", "Type:", "Source Type:") with chalk.dim() where the integration details
are printed (the block referencing integration.id, integration.appId,
integration.ruleType, integration.source.type), so each line becomes a dimmed
label followed by the value.

src/commands/channels/presence/subscribe.ts-38-42 (1)

38-42: ⚠️ Potential issue | 🟡 Minor

Duration flag description doesn't match coding guidelines.

The description was changed to "Automatically exit after N seconds" but the coding guidelines specify the exact wording should be "Automatically exit after N seconds (0 = run indefinitely)" with alias -D. The (0 = run indefinitely) part helps users understand that 0 or omitting the flag means indefinite execution.

🔧 Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/channels/presence/subscribe.ts` around lines 38 - 42, Update the
duration flag definition in subscribe.ts (the Flags.integer call for the
duration flag) to use the exact description "Automatically exit after N seconds
(0 = run indefinitely)" and ensure the short alias remains -D (char: "D") so the
flag matches the coding guideline.

src/commands/logs/channel-lifecycle/subscribe.ts-27-31 (1)

27-31: ⚠️ Potential issue | 🟡 Minor

Use the standardized --duration description text

Please update the description to include "(0 = run indefinitely)" for consistency with command guidelines.

Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines, "--duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/channel-lifecycle/subscribe.ts` around lines 27 - 31,
Update the duration flag definition used in subscribe.ts so its description
matches the standard text: change the Flags.integer({ description:
"Automatically exit after N seconds" ... }) to use "Automatically exit after N
seconds (0 = run indefinitely)" and keep the alias char: "D" and required: false
on the same Flags.integer call for the duration flag.

src/commands/channels/occupancy/subscribe.ts-36-40 (1)

36-40: ⚠️ Potential issue | 🟡 Minor

Align --duration description with the command guideline

duration uses -D correctly, but the description is missing the required "(0 = run indefinitely)" suffix.

Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines, "--duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/channels/occupancy/subscribe.ts` around lines 36 - 40, The
duration flag in src/commands/channels/occupancy/subscribe.ts uses Flags.integer
but its description is missing the required suffix; update the description for
the duration flag (the Flags.integer call named duration) to read "Automatically
exit after N seconds (0 = run indefinitely)" and keep the existing alias char:
"D".

src/commands/accounts/login.ts-230-230 (1)

230-230: ⚠️ Potential issue | 🟡 Minor

Avoid colored resource text inside progress() action text

progress() action text should stay uncolored; resource(appName) introduces color here.

Suggested fix

-              this.log(`\n${progress(`Creating app ${resource(appName)}`)}`);
+              this.log(`\n${progress(`Creating app ${appName}`)}`);

As per coding guidelines, "Use progress() helper for in-progress actions (no color on action text, ends with '...')."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/accounts/login.ts` at line 230, The progress action text
currently includes colored output via resource(appName) inside the progress(...)
call in the this.log(...) statement; replace the colored helper with plain
appName (or a stripped/colorless version) and ensure the progress text ends with
'...' so use progress(`Creating app ${appName}...`) (or progress(`Creating app
${stripColor(appName)}...`) if you need to strip color elsewhere) instead of
progress(`Creating app ${resource(appName)}`).

src/commands/bench/subscriber.ts-36-39 (1)

36-39: ⚠️ Potential issue | 🟡 Minor

Align --duration description with the standard text

Please include the (0 = run indefinitely) suffix in the help text for consistency.

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/bench/subscriber.ts` around lines 36 - 39, Update the duration
flag's description on the Flags.integer call for `duration` (the flag with char
"D") to match the standard text: change the description to "Automatically exit
after N seconds (0 = run indefinitely)". Ensure you only modify the description
string for the `duration` flag in the subscriber command where `duration:
Flags.integer({ char: "D", ... })` is defined.

src/commands/rooms/presence/enter.ts-46-48 (1)

46-48: ⚠️ Potential issue | 🟡 Minor

Use the standard --duration description text

Line 47 should include the indefinite-run hint for consistency across long-running commands.

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/presence/enter.ts` around lines 46 - 48, Update the
duration flag declaration in enter.ts so its description matches the standard
text and alias: change the Flags.integer description to "Automatically exit
after N seconds (0 = run indefinitely)" and ensure the char/alias is set to "D"
(refer to the duration flag definition in this file).

src/commands/logs/subscribe.ts-29-31 (1)

29-31: ⚠️ Potential issue | 🟡 Minor

Restore the standard --duration help text

Line 30 should include the indefinite-run note to match command help consistency.

Suggested fix

 duration: Flags.integer({
-  description: "Automatically exit after N seconds",
+  description: "Automatically exit after N seconds (0 = run indefinitely)",
   char: "D",
   required: false,
 }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/subscribe.ts` around lines 29 - 31, Update the
Flags.integer definition for the duration flag in subscribe.ts (the duration
flag declaration) to restore the standard help text: set its description to
"Automatically exit after N seconds (0 = run indefinitely)" and ensure the char
alias remains "D" so the --duration flag matches the project guideline and help
output.

src/commands/rooms/typing/subscribe.ts-30-33 (1)

30-33: ⚠️ Potential issue | 🟡 Minor

Align --duration description with the shared command contract.

Line 31 should include the indefinite-run note for consistency across long-running commands.

Suggested fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/typing/subscribe.ts` around lines 30 - 33, The --duration
flag in the subscribe command currently has an incomplete description; update
the duration Flags.integer declaration (the duration flag in
src/commands/rooms/typing/subscribe.ts) so its description reads "Automatically
exit after N seconds (0 = run indefinitely)" and ensure the char alias is '-D'
(char: "D") to match the shared long-running command contract.

src/commands/logs/connection-lifecycle/subscribe.ts-22-24 (1)

22-24: ⚠️ Potential issue | 🟡 Minor

Use the standard --duration description text.

Line 23 should include the standard suffix for indefinite mode to match command consistency.

Suggested fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/connection-lifecycle/subscribe.ts` around lines 22 - 24,
Update the duration flag description to the standard text and keep the alias; in
the Flags.integer call for the duration flag in subscribe.ts (the duration:
Flags.integer({...}) object), change description to "Automatically exit after N
seconds (0 = run indefinitely)" and ensure the char remains "D" so the flag
matches the project's standard --duration wording and alias.

src/commands/logs/push/subscribe.ts-27-31 (1)

27-31: ⚠️ Potential issue | 🟡 Minor

Use the standard --duration help text

Keep the duration description consistent with other commands and docs.

Suggested change

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/push/subscribe.ts` around lines 27 - 31, The duration flag
definition (duration: Flags.integer) uses a non-standard description; update its
description to "Automatically exit after N seconds (0 = run indefinitely)" and
ensure the alias/char remains "D" and required stays false so it matches other
commands and docs (change only the description string in the duration:
Flags.integer declaration).

src/commands/spaces/members/subscribe.ts-31-34 (1)

31-34: ⚠️ Potential issue | 🟡 Minor

Normalize --duration description text

Please use the shared duration wording used across long-running commands.

Suggested change

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/members/subscribe.ts` around lines 31 - 34, Update the
duration flag in the subscribe command so its description uses the shared
wording and alias: change the description string in the duration:
Flags.integer({ ... }) definition inside
src/commands/spaces/members/subscribe.ts to "Automatically exit after N seconds
(0 = run indefinitely)" and ensure the flag has char: "D" set (alias -D) and
required: false stays unchanged.

src/commands/rooms/messages/subscribe.ts-65-67 (1)

65-67: ⚠️ Potential issue | 🟡 Minor

Align --duration description with the CLI standard

The description should include the indefinite-run behavior note for consistency across long-running commands.

Suggested change

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/messages/subscribe.ts` around lines 65 - 67, Update the
duration flag metadata in the subscribe command: change the Flags.integer
description for the duration flag to "Automatically exit after N seconds (0 =
run indefinitely)" and ensure its alias remains char: "D" (the duration flag
definition using Flags.integer in subscribe.ts).

src/commands/spaces/cursors/subscribe.ts-36-38 (1)

36-38: ⚠️ Potential issue | 🟡 Minor

Use the standard help text for --duration.

Line 37 should include (0 = run indefinitely) for consistency across long-running commands.

Proposed fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines src/commands/**/*.ts: The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/cursors/subscribe.ts` around lines 36 - 38, The duration
flag's help text and alias need to follow the standard: update the Flags.integer
declaration for the duration flag (the symbol named duration in subscribe.ts) so
its description reads "Automatically exit after N seconds (0 = run
indefinitely)" and ensure the single-character alias is "D" (i.e., char: "D").

src/commands/spaces/locks/acquire.ts-36-39 (1)

36-39: ⚠️ Potential issue | 🟡 Minor

Standardize the --duration description text.

Line 37 should include the (0 = run indefinitely) suffix to match CLI conventions.

Proposed fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines src/commands/**/*.ts: The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/locks/acquire.ts` around lines 36 - 39, Update the
duration flag's description in the Flags.integer call for the duration option so
it reads "Automatically exit after N seconds (0 = run indefinitely)"; ensure
this change is applied inside the duration: Flags.integer({ ... }) block and
retain the alias char: "D" so the flag remains available as -D.

.cursor/rules/AI-Assistance.mdc-135-135 (1)

135-135: ⚠️ Potential issue | 🟡 Minor

Keep the rule file consistent with the enforced --duration convention.

Line 135 currently contradicts the command guideline and will propagate inconsistent help text.

Proposed fix

-- `--duration`: `"Automatically exit after N seconds"`, alias `-D`
+- `--duration`: `"Automatically exit after N seconds (0 = run indefinitely)"`, alias `-D`

As per coding guidelines src/commands/**/*.ts: The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.cursor/rules/AI-Assistance.mdc at line 135, Update the `--duration` flag
entry in the AI-Assistance.mdc rule file so it matches the enforced convention:
change its description to 'Automatically exit after N seconds (0 = run
indefinitely)' and ensure the alias is `-D` for the `--duration` flag (look for
the `--duration` token on line containing the flag description to locate the
entry).

src/commands/rooms/typing/keystroke.ts-43-47 (1)

43-47: ⚠️ Potential issue | 🟡 Minor

Align --duration help text with the command convention.

Line 44 omits the (0 = run indefinitely) suffix used across commands.

Proposed fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines src/commands/**/*.ts: The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/typing/keystroke.ts` around lines 43 - 47, Update the
duration flag's description to match the project convention: change the
Flags.integer description for the duration flag (the property named duration
using Flags.integer) to "Automatically exit after N seconds (0 = run
indefinitely)"; keep the alias/char as "D" unchanged so the flag remains
available as -D.

src/commands/rooms/occupancy/subscribe.ts-45-47 (1)

45-47: ⚠️ Potential issue | 🟡 Minor

Use the standard --duration description string.

Line 46 should include the indefinite-run note for consistency with other long-running commands.

Proposed fix

-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",

As per coding guidelines src/commands/**/*.ts: The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/occupancy/subscribe.ts` around lines 45 - 47, Update the
duration flag in src/commands/rooms/occupancy/subscribe.ts: modify the
Flags.integer configuration for the "duration" flag (symbol: duration, char:
"D") so its description exactly reads "Automatically exit after N seconds (0 =
run indefinitely)" to match the standard long-running command phrasing and
retain the alias -D.

src/commands/spaces/locations/subscribe.ts-55-57 (1)

55-57: ⚠️ Potential issue | 🟡 Minor

Restore the standard --duration help text

The current description drops the documented 0 semantics.

Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/locations/subscribe.ts` around lines 55 - 57, Update the
duration flag definition in subscribe.ts (the duration: Flags.integer({...})
entry) to restore the standard help text: set description to "Automatically exit
after N seconds (0 = run indefinitely)" and ensure the alias char remains "D"
(i.e., preserve char: "D"); no other behavior changes required.

src/commands/rooms/messages/reactions/subscribe.ts-47-49 (1)

47-49: ⚠️ Potential issue | 🟡 Minor

Align --duration description with command standard

Please include the (0 = run indefinitely) behavior in the help text.

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/messages/reactions/subscribe.ts` around lines 47 - 49,
Update the --duration flag description to include the "(0 = run indefinitely)"
behavior; in the options definition for the duration flag (the object with
description: "Automatically exit after N seconds", char: "D", required: false in
subscribe.ts) replace the description string with "Automatically exit after N
seconds (0 = run indefinitely)" and ensure the alias char remains "D".

src/commands/spaces/locks/subscribe.ts-35-37 (1)

35-37: ⚠️ Potential issue | 🟡 Minor

Use the standard --duration description text

The description should explicitly document the 0 behavior for indefinite run.

Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/locks/subscribe.ts` around lines 35 - 37, Update the
duration flag declaration (duration: Flags.integer) to use the standard
description text "Automatically exit after N seconds (0 = run indefinitely)" and
ensure the alias char is '-D' (or char: "D") to match guidelines; locate the
duration flag in subscribe.ts (the duration: Flags.integer({...}) block) and
replace the current description with the exact required string.

src/commands/rooms/messages/history.ts-92-94 (1)

92-94: ⚠️ Potential issue | 🟡 Minor

Progress text is inaccurate for --order oldestFirst

The message always says “most recent messages,” which is misleading when users request oldest-first order.

Suggested wording

-              `Fetching ${flags.limit} most recent messages from room ${resource(args.room)}`,
+              `Fetching up to ${flags.limit} messages from room ${resource(args.room)}`,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/messages/history.ts` around lines 92 - 94, Update the
progress message in the call to progress(...) so it reflects the requested
ordering: check the CLI flag used for ordering (e.g., flags.order or a boolean
like flags.oldestFirst) and change the text from "Fetching ${flags.limit} most
recent messages from room ${resource(args.room)}" to conditionally say "most
recent messages" when order is newest-first and "oldest messages" (or "oldest
messages first") when order is oldestFirst (i.e., when flags.order ===
'oldestFirst' or flags.oldestFirst is true); keep using flags.limit and
resource(args.room) and only alter the descriptive text.

src/commands/support/ask.ts (1)

38-41: Use shared progress() output helper instead of raw ora

This command is still using ora(...) directly for in-progress output. Please switch to the shared progress() helper for consistent CLI output behavior across commands.

As per coding guidelines "Use progress() helper for in-progress actions (no color on action text, ends with '...')".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/support/ask.ts` around lines 38 - 41, Replace the direct ora
usage that sets spinner in the ask command with the shared progress() helper:
instead of creating spinner via ora("Thinking...").start(), call
progress("Thinking") when interactive output and JSON output are not enabled
(same condition using isInteractive || this.shouldOutputJson(flags)), and store
the returned progress handle in the same spinner variable so existing
stop/succeed calls still work; ensure the action text passed to progress has no
color and does not include the trailing ellipsis (progress will append "..."
itself).

test/unit/commands/stats/account.test.ts (1)

1-26: Use constructor-level Ably SDK stubbing for .test.ts

This file relies on network interception only. For unit-level isolation in this repo, please stub Ably.Rest constructor with sinon and restore in afterEach.

As per coding guidelines: "Mock the Ably SDK constructor (Ably.Rest) using sinon stubs, not just individual methods, and always restore stubs in afterEach".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/commands/stats/account.test.ts` around lines 1 - 26, The test
currently relies only on nock; instead stub the Ably SDK constructor Ably.Rest
using sinon so the test is unit-scoped: import sinon and Ably, then in
beforeEach create a sinon.stub(Ably, "Rest").callsFake(() => ({ /* return the
minimal instance used by stats:account, e.g. stats: { get:
sinon.stub().resolves(mockStats) } */ })); use that stubbed instance to satisfy
the command run and keep the existing process.env setup; in afterEach restore
the stub by calling sinon.restore() (or (Ably.Rest as any).restore()) and keep
nock.cleanAll() so all stubs are removed between tests.

test/unit/commands/rooms/messages.test.ts (1)

437-440: Harden the relative-time assertion against runtime jitter.

This assertion can be flaky under slower CI timing. Consider validating against a captured before/after execution range instead of a single Date.now() sample.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/commands/rooms/messages.test.ts` around lines 437 - 440, Replace
the single Date.now() sample check with a before/after range: capture const
before = Date.now() before you call the code that triggers
room.messages.history, and const after = Date.now() immediately after; then
assert callArgs.start is >= before - 5000 and <= after + 5000 (or tighter) so
the expectation around room.messages.history.mock.calls[0][0].start is tolerant
to CI jitter.

test/unit/commands/channels/history.test.ts (1)

191-195: Make relative-time assertions deterministic to reduce flaky CI runs.

These checks rely on wall-clock timing with a fixed ±5s window. On slow runners, that can fail intermittently. Prefer asserting within a before/after window captured around command execution (or use a fixed clock).

Also applies to: 207-211

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/commands/channels/history.test.ts` around lines 191 - 195, The
relative-time assertions around channel.history.mock.calls[0][0].start are flaky
because they use Date.now() directly; instead capture a deterministic
before/after window around the command execution (e.g., const before =
Date.now(); run the code that triggers channel.history(...); const after =
Date.now();) and then assert callArgs.start is between before - tolerance and
after + tolerance (or use a mocked/fixed clock). Apply the same change for the
other similar assertions (the later block referencing channel.history.mock.calls
and its start value) so both tests use captured before/after timestamps (or a
fixed clock) rather than a single Date.now() comparison.

src/commands/spaces/locks/acquire.ts (1)

46-51: Release in finally should be gated by successful acquisition.

this.lockId is set from args before acquire, so Line 48 can attempt a release even when lock acquisition failed. Track acquisition state to avoid unnecessary release calls and noisy final-release errors.

Proposed fix

 export default class SpacesLocksAcquire extends SpacesBaseCommand {
   ...
   private lockId: null | string = null;
+  private lockAcquired = false;
 ...
   async finally(err: Error | undefined): Promise<void> {
-    if (this.lockId && this.space) {
+    if (this.lockAcquired && this.lockId && this.space) {
       try {
         await this.space.locks.release(this.lockId);
       } catch (error) {
         ...
       }
     }
 ...
         const lock = await this.space.locks.acquire(
           lockId,
           lockData as LockOptions,
         );
+        this.lockAcquired = true;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/locks/acquire.ts` around lines 46 - 51, The finally block
currently tries to release the lock whenever this.lockId is present, but
this.lockId is populated from args before acquire and can cause release attempts
when acquisition failed; introduce and set a boolean flag (e.g.,
this.lockAcquired or this.acquired) to true only after a successful call to the
acquire logic, then change the finally check to require both this.lockId and the
acquisition flag before calling this.space.locks.release(this.lockId) so release
is only attempted for locks that were actually acquired.

test/unit/commands/stats/app.test.ts (1)

33-36: Strengthen query assertions for time-range parsing.

query(true) only proves “some query exists”; it doesn’t verify that --start/--end were parsed and sent correctly. Please assert expected query keys/format so timestamp parsing regressions fail.

Suggested test hardening

-      .query(true)
+      .query((queryObject) => {
+        // ISO / unix-ms paths should produce numeric ms values
+        return typeof queryObject.start === "string" && /^\d+$/.test(queryObject.start);
+      })

-      .query(true)
+      .query((queryObject) => {
+        // ISO test should include end as well
+        return (
+          typeof queryObject.start === "string" &&
+          /^\d+$/.test(queryObject.start) &&
+          typeof queryObject.end === "string" &&
+          /^\d+$/.test(queryObject.end)
+        );
+      })

As per coding guidelines **/*.test.{ts,js}: Update or add Unit, Integration, and E2E tests as appropriate for your changes, following the testing strategy defined in docs/Testing.md.

Also applies to: 55-58, 70-73

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/commands/stats/app.test.ts` around lines 33 - 36, Replace the loose
.query(true) nock matchers for the stats endpoint with specific assertions that
validate the start/end query params and their format: locate the nock setup that
creates scope from
nock("https://control.ably.net").get(`/v1/apps/${appId}/stats`) and change
.query(true) to either .query({ start: expectedStartIso, end: expectedEndIso })
when exact values are known, or .query(q => { return typeof q.start === 'string'
&& typeof q.end === 'string' && ISO_TIMESTAMP_REGEX.test(q.start) &&
ISO_TIMESTAMP_REGEX.test(q.end); }) to assert timestamp parsing; apply the same
change to the other occurrences of .query(true) for stats tests so regressions
in parsing --start/--end fail the tests.

src/commands/spaces/locks/subscribe.ts (1)

277-277: Style event action labels consistently

Consider highlighting updated as an event label using chalk.yellow() for consistency with other event outputs.

Suggested tweak

-            `${formatTimestamp(timestamp)} Lock ${chalk.blue(lock.id)} updated`,
+            `${formatTimestamp(timestamp)} Lock ${chalk.blue(lock.id)} ${chalk.yellow("updated")}`,

As per coding guidelines: "Use chalk.yellow() for event type labels in output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/spaces/locks/subscribe.ts` at line 277, Change the event label
styling so the word "updated" is highlighted with chalk.yellow() for consistency
with other event outputs; locate the formatted message that uses
formatTimestamp(timestamp) and chalk.blue(lock.id) (in subscribe.ts) and replace
the plain "updated" label with chalk.yellow("updated") so the output reads
`${formatTimestamp(timestamp)} Lock ${chalk.blue(lock.id)}
${chalk.yellow('updated')}` (ensure spacing/concatenation matches surrounding
messages).

src/utils/time.ts:1

• The docstring says “ISO 8601 or any Date-parseable string”, but the implementation now rejects non-ISO strings via the isIso regex guard. Update the comment to match actual behavior (e.g., “ISO 8601 only”) or relax the validation to allow general Date-parseable inputs.
  src/utils/time.ts:1
• The regex permits date-times with no timezone (the (Z|[+-]...)? is optional), which new Date() interprets in local time. That makes parseTimestamp("2023-01-01T00:00") machine/timezone-dependent and can lead to inconsistent CLI behavior. Consider requiring an explicit timezone on date-time inputs (keep date-only as-is), or normalize timezone-less inputs to UTC explicitly.
  src/commands/queues/delete.ts:1
• In --json mode with no --force, the command will skip confirmation and proceed with deletion. To avoid accidental destructive actions in non-interactive/scripted usage, consider requiring --force whenever confirmation cannot be shown (e.g., --json or non-TTY), and emit a structured JSON error telling the user to pass --force.
  src/commands/spaces/cursors/get-all.ts:1
• This changes cursor updates from an in-place terminal update (process.stdout.write("\r...")) to line-by-line logging. For long-running subscriptions this can generate a lot of output (and slow down / bloat logs). If shouldUseTerminalUpdates() still exists, consider restoring the in-place update for TTY (non-JSON) and falling back to this.log() only for non-TTY or when explicitly requested.
  test/unit/commands/stats/app.test.ts:1
• These tests validate that the command runs, but .query(true) doesn’t assert that --start/--end are actually parsed and sent correctly (especially important for relative timestamps). Consider freezing time (fake timers) and asserting the exact expected query params (or at least that start/end exist and are numeric ms) so regressions in parseTimestamp() wiring are caught.

src/commands/logs/connection-lifecycle/subscribe.ts (2)

22-26: Duration flag description is incomplete per coding guidelines.

The description should include the (0 = run indefinitely) clarification.

📝 Suggested fix

     duration: Flags.integer({
-      description: "Automatically exit after N seconds",
+      description: "Automatically exit after N seconds (0 = run indefinitely)",
       char: "D",
       required: false,
     }),

As per coding guidelines: "The --duration flag should have description 'Automatically exit after N seconds (0 = run indefinitely)' with alias -D".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/connection-lifecycle/subscribe.ts` around lines 22 - 26,
The duration flag definition (duration: Flags.integer) has an incomplete
description; update its description to "Automatically exit after N seconds (0 =
run indefinitely)" and ensure the alias char remains "D" (alias -D) in the
Flags.integer call so the flag matches coding guidelines; locate the duration
flag in subscribe.ts and replace the current description string accordingly.

---

106-110: Secondary label should use chalk.dim() instead of chalk.green().

Per the PR objectives and coding guidelines, secondary labels like "Data:" should use chalk.dim() rather than chalk.green().

📝 Suggested fix

           if (message.data !== null && message.data !== undefined) {
             this.log(
-              `${chalk.green("Data:")} ${JSON.stringify(message.data, null, 2)}`,
+              `${chalk.dim("Data:")} ${JSON.stringify(message.data, null, 2)}`,
             );
           }

As per coding guidelines: "Use chalk.dim() for secondary labels like field names in structured output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/connection-lifecycle/subscribe.ts` around lines 106 - 110,
The secondary label "Data:" in the message handling of the subscribe command is
using chalk.green(); change it to chalk.dim() so secondary labels follow the
project's style guide—locate the block that checks message.data !== null &&
message.data !== undefined inside the subscribe handler and replace
chalk.green("Data:") with chalk.dim("Data:") in the this.log call that
JSON.stringifies message.data.

test/unit/commands/queues/delete.test.ts (1)

421-423: Consider updating skipped test expectations for consistency.

These skipped tests still expect the old message format (Queue "${mockQueueName}" and "deleted successfully"), while the active tests now expect "Queue deleted:". If these tests are ever unskipped, they would fail due to the format mismatch.

💡 Suggested update

-      expect(stdout).toContain(`Queue "${mockQueueName}"`);
-      expect(stdout).toContain("deleted successfully");
+      expect(stdout).toContain("Queue deleted:");

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/commands/queues/delete.test.ts` around lines 421 - 423, The skipped
assertions in delete.test.ts still expect the old output format ("Queue
\"${mockQueueName}\"" and "deleted successfully") which now conflicts with
active tests that assert "Queue deleted:"; update the skipped test expectations
to match the new format by changing the expect calls that reference stdout and
mockQueueName to assert the "Queue deleted:" style (use the same stdout contains
checks as the active tests) so that if the tests are unskipped they will pass
consistently with the current output formatting.

src/commands/apps/set-apns-p12.ts (1)

57-59: Progress message should end with ...

Per coding guidelines, progress messages should end with ... to indicate an in-progress action.

Suggested fix

     this.log(
-      progress(`Uploading APNS P12 certificate for app ${resource(args.id)}`),
+      progress(`Uploading APNS P12 certificate for app ${resource(args.id)}...`),
     );

As per coding guidelines: "Use progress() helper for in-progress actions (no color on action text, ends with '...')"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/apps/set-apns-p12.ts` around lines 57 - 59, The progress message
logged by this.log(progress(...)) does not end with an ellipsis; update the
string passed to progress in the set-apns-p12 command so it ends with "..."
(e.g. change `Uploading APNS P12 certificate for app ${resource(args.id)}` to
`Uploading APNS P12 certificate for app ${resource(args.id)}...`). Locate the
call to progress(...) inside the command (the this.log(progress(...))
invocation) and append the three dots to the template literal so the progress
helper output follows the coding guideline.

.claude/CLAUDE.md (1)

127-127: Consider expanding the relative time format examples.

The documentation shows examples "1h", "30m", "2d", but the PR summary indicates additional supported formats including "30s", "5m", and "1w". Including a more comprehensive set of examples would help developers understand the full range of supported formats.

📝 Suggested enhancement

-- **`timeRangeFlags`** — `--start`, `--end`. Use for history and stats commands. Parse with `parseTimestamp()` from `src/utils/time.ts`. Accepts ISO 8601, Unix ms, or relative (e.g., `"1h"`, `"30m"`, `"2d"`).
+- **`timeRangeFlags`** — `--start`, `--end`. Use for history and stats commands. Parse with `parseTimestamp()` from `src/utils/time.ts`. Accepts ISO 8601, Unix ms, or relative (e.g., `"30s"`, `"5m"`, `"1h"`, `"2d"`, `"1w"`).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.claude/CLAUDE.md at line 127, Update the documentation for timeRangeFlags
to show a more comprehensive set of relative time examples supported by
parseTimestamp() in src/utils/time.ts (e.g., "30s", "1m", "5m", "30m", "1h",
"1d", "2d", "1w") so readers clearly see seconds/minutes/hours/days/weeks are
accepted; edit the line describing **`timeRangeFlags`** (the `--start`, `--end`
examples) to include these additional relative formats.

src/commands/integrations/delete.ts (1)

92-116: Consider using chalk.dim() for secondary field labels.

The JSON output structure looks good. For the non-JSON output, the coding guidelines recommend using chalk.dim() for secondary labels like field names in structured output. The labels on lines 112-115 (ID:, App ID:, etc.) could use this styling for consistency with other commands.

♻️ Optional: Apply chalk.dim() to field labels

Add chalk import:

+import chalk from "chalk";
 import { Args, Flags } from "@oclif/core";

Then update the output:

       } else {
         this.log(
           success(`Integration rule deleted: ${resource(integration.id)}.`),
         );
-        this.log(`ID: ${integration.id}`);
-        this.log(`App ID: ${integration.appId}`);
-        this.log(`Type: ${integration.ruleType}`);
-        this.log(`Source Type: ${integration.source.type}`);
+        this.log(`${chalk.dim("ID:")} ${integration.id}`);
+        this.log(`${chalk.dim("App ID:")} ${integration.appId}`);
+        this.log(`${chalk.dim("Type:")} ${integration.ruleType}`);
+        this.log(`${chalk.dim("Source Type:")} ${integration.source.type}`);
       }

As per coding guidelines: "Use chalk.dim() for secondary labels like field names in structured output".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/integrations/delete.ts` around lines 92 - 116, The non-JSON
output in the delete command prints field labels as plain text—wrap the
secondary labels (the static parts in the this.log calls that print `ID:`, `App
ID:`, `Type:`, `Source Type:`) with chalk.dim() for consistent styling; add an
import for chalk at the top of the file and update the four this.log(...) lines
in the else branch (the block guarded by this.shouldOutputJson(flags) and using
success(), resource(), and formatJsonOutput) so each static label is formatted
via chalk.dim() while keeping the dynamic values unchanged.

src/commands/support/ask.ts (1)

38-43: Use the shared progress() helper here.

This branch re-implements the in-progress UI with ora plus a manual this.log("Thinking..."), so support ask now diverges from the shared command UX the rest of this PR is standardizing. Routing this through progress("Thinking...") would keep the behavior consistent in one place.

As per coding guidelines, "Use progress() helper for in-progress actions (no color on action text, ends with '...')".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/support/ask.ts` around lines 38 - 43, Replace the ad-hoc ora
spinner and manual this.log("Thinking...") with the shared progress helper:
remove the ora creation and the conditional this.log call in the support ask
command and instead call progress("Thinking...") where the current spinner logic
runs (respecting the same isInteractive / shouldOutputJson(flags) condition);
ensure you import or reference the progress() helper and use its returned
handle/stop behavior consistent with other commands so the in-progress UI
matches the shared UX.

test/unit/utils/time.test.ts (1)

83-88: Always restore fake timers in this test.

If the assertion on Line 87 fails, Line 88 never runs and the suite keeps fake timers enabled. Wrap this setup in try/finally or move it into a nested beforeEach/afterEach block for the whitespace suite.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@test/unit/utils/time.test.ts` around lines 83 - 88, The test "should trim
whitespace from relative input" uses vi.useFakeTimers() but may leave fake
timers enabled if the assertion throws; wrap the fake-timer setup and assertion
in a try/finally (or move to a nested beforeEach/afterEach) so
vi.useRealTimers() always runs. Specifically, in the test containing
parseTimestamp(" 1h "), ensure vi.useRealTimers() is called in a finally block
(or ensure the whitespace suite uses beforeEach to call vi.useFakeTimers() and
afterEach to call vi.useRealTimers()) so timers are always restored even on
assertion failure.

src/commands/rooms/messages/history.ts (1)

67-69: Unreachable code after this.error().

In oclif, this.error() throws an exception and never returns, making the return statement on line 68 unreachable. While harmless, it can be removed for clarity.

Proposed fix

       if (!chatClient) {
         this.error("Failed to create Chat client");
-        return;
       }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/rooms/messages/history.ts` around lines 67 - 69, The code calls
this.error("Failed to create Chat client") which in oclif throws and never
returns, so remove the redundant unreachable return statement immediately after
it (in the same block where the Chat client is created), leaving only the
this.error(...) call; locate the occurrence in the history command handler (the
method containing the Chat client creation) and delete the trailing return to
clean up unreachable code.

src/commands/logs/push/history.ts (1)

2-2: Make ably a type-only import

Ably is only used for a type annotation here. Switching this to import type avoids a needless runtime import under type-preserving TS emits and usually keeps consistent-type-imports-style lint rules happy.

♻️ Proposed fix

-import * as Ably from "ably";
+import type * as Ably from "ably";

As per coding guidelines, "Ensure all code passes ESLint linter checks using pnpm exec eslint."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/commands/logs/push/history.ts` at line 2, Replace the runtime import of
Ably with a type-only import since the symbol Ably is used only for type
annotations; change the import statement that currently reads `import * as Ably
from "ably";` to a type-only import (e.g., using `import type`) so the module is
not included at runtime and ESLint consistent-type-imports rules are satisfied,
then run the linter to verify (refer to the Ably symbol in this file when making
the change).